NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/442

Internet Message Format | 1996-08-06 | 4KB

Path: newshost.lanl.gov!tanmoy
From: [e-mail] (Tanmoy Bhattacharya)
Newsgroups: comp.std.c
Subject: Re: setjmp usage question
Date: 25 Feb 1996 17:43:18 GMT
Organization: Los Alamos National Laboratory
Message-ID: <[e-mail]>
References: <4gnusq$[e-mail]>
NNTP-Posting-Host: qcd.lanl.gov
Mime-Version: 1.0
Content-Type: text
In-reply-to: [e-mail]'s message of 24 Feb 1996 21:10:50 GMT

In article <4gnusq$[e-mail]>
[e-mail] (Michael J Zehr) writes:

<snip showing env_index is not a block scope variable>
MJZ:   if (*error_code = setjmp(env[env_index++])) {
<snip>
MJZ:   longjmp(env[env_index], 1);

This brings in undefined behaviour, you cannot assign the result of
setjmp to anything: an easy way to remember what operations are
allowed is by remembering that setjmp may be implemented as a jump
table instead of as `returning a value' (This is just a mnemonic, the
actual rules are clearly stated in the standard). Thus its use alone,
or with a single comparison or negation, as the control expression of
if, while, switch etc. are perfectly valid; as is ignoring the result
altogether. Any bigger expression containing it is disallowed, as is
an assignment `because' it needs a returned value.

MJZ: Should this code work correctly?  In particular, can a compiler
MJZ: increment env_index after longjmp is called?

I do not think so. Even though setjmp may be invoked as a macro and
hence it may not have a sequence point before the call, its uses are
so limited that the sequence point at the end of the complete
expression (in this case the one controlling the `if') usually works
well enough. So if you hadn't invoked undefined behaviour, env_index
necessarily gets incremented before the branch controlled by the if is
taken.

MJZ:
MJZ: [Additional question because I'm curious:  what happens to
MJZ: post-increments that are in parameters of the longjmp call?  Are they
MJZ: ever executed?  I suppose the general question is where are the sequence
MJZ: points when you're using setjmp and lonjmp?]
MJZ:

If there is a sequence point before the longjmp call, the increment
must take place (because it is not a block scope non-volatile
variable, and therefore must retain its value from the moment of the
longjmp call). longjmp is described as a function, and hence if you
write the call as (longjmp)(...), the function semantics definitely
applies.

I believe that the standard meant that when functions are implemented
as a macro, the implementation cannot change any of the
semantics. Unfortunately, this is not completely clarified in the
standard. I hope that the standard will clarify one day that even when
something described as a function is implemented as a macro,

1) prototype checking and argument conversion must take place,
2) there should be a sequence point between the evaluation of the
   parameters and the rest of the evaluation.

By the as-if rules, these may be elided ... but one should not have to
consider these when analyzing the meaning of a program. As it stands,
I think that the standard does not do so very clearly (i.e. there have
been varying opinions here on comp.std.c): to be safe, one should
currently use the function version instead of the macro version if one
needs the sequence point.

Cheers
Tanmoy
--
[e-mail](128.165.23.46) DECNET: BETA::"[e-mail]"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: [phone]   voice: 1 [phone]    [ Home: 1 [phone] ]